Subject: Electronic AP for DLSw Multicast Spec

From: David Bryant/HQ/3Com <[email-masked]>
Date: 23 Aug 96 17:15:14 EDT

Folks - 

Sorry about the delay in getting this out... some hand-off problems and 
excessive travel problems.   Anyway, here's an updated copy of the DLSw 
Multicast Spec from AIW 11.    Please post all comments to this forum.  If we 
receive no significant objections b 9/13/96, we will declare the specification 
to be AP.     I'll post a Microsoft Word version of the document early next 
week and let ya all know where it is.  

Cheers, 
Dave

David Bryant 3Com Corp        October 1995
Mike Redden  Proteon Inc        Revised 7/96
Paul Britton  Data Connection Ltd.

A submission to the APPN Implementers Workshop
Draft Proposal for Approved Pages Status
at 
AIW 11 
July 1996, NC

DLSw Multicast Protocol Enhancements

Background
RFC 1795 specifies an AIW standard for the Switch to Switch Protocol (SSP) of 
Data Link Switching (DLSw).   Through implementation and installation 
experiences, vendors have become increasingly more concerned with the 
scalability of DLSw protocols in large networking situations.  Accordingly, a 
DLSw Scalability group has been established within the AIW to define a set of 
DLSw protocol enhancements for the purpose of improving DLSw scalability. 

It is assumed that the reader is familiar with DLSw and RFC 1795.  No effort 
has been made to explain those protocols or associated terminology.  Note: 
Throughout this document the acronym SSP has been used interchangeably to refer 
to both the switch to switch protocol of DLSw and the set of state machines 
which implement the protocol.  However, the endpoint of an SSP message exchange 
is referred to as a DLSw.

Intent

This document defines a set of SSP protocol enhancements to RFC 1795 which will 
improve the scalability of DLSw.  These enhancements are designed to be fully 
backward compatible with existing  RFC 1795 implementations.   Once completed 
and approved within the AIW, it is the intent of the DLSw Scalability group  to 
submit these enhancements to the IETF in the form of an informational RFC.  As 
a compatible set of optional enhancements to RFC 1795, this document does not 
replace or supersede RFC 1795. 

Scope

The DLSw Scalability group of the AIW has identified a number of scalability 
issues associated with existing DLSw protocols as defined in RFC 1795: 

z Administration
 
 RFC 1795 implies the need to define the transport address of all peer DLSws at 
each DLSw.  In highly meshed situations (such as those often found in NetBIOS 
networks), the resultant administrative burden is undesirable.
 
z Address Resolution
 
 RFC 1795 defines point to point TCP (or other reliable transport protocol) 
connections between each DLSw.  When attempting to discover the location of an 
unknown resource, a DLSw sends an address resolution packet to each partner 
DLSw over these connections.  In highly meshed configurations, this can result 
in a very large number of packets in the transport network.  Although each 
packet is sent individually to each DLSw partner, they are each identical in 
nature.  Thus the transport network is burdened with excessive numbers of 
identical packets.  Since the transport network is most commonly a wide area 
network where bandwidth is considered a precious resource, this packet 
duplication is undesirable. 

z Broadcast Packets
 
 In addition to the address resolution packets described above, RFC 1795 also 
propagates NetBIOS broadcast packets into the transport network.  The UI frames 
of NetBIOS are sent as LAN broadcast packets and RFC 1795  DLSws propagate 
these packets over the point to point transport connections to each DLSw 
partner.  In the same manner as above, this creates a large number of identical 
packets in the transport network.  This is also considered undesirable.  And 
because NetBIOS UI frames can be sent by applications, it is difficult to 
predict or control the rate and quantity of such traffic.   This compounds the 
undesirability of the existing RFC 1795 propagation method for these packets.
 
z TCP (transport connection) Overhead
 
  As defined in RFC 1795, each DLSw maintains a transport connection to its 
peer DLSw partners.  Each transport connection guarantees in order packet  
delivery.   This is accomplished using acknowledgment and sequencing algorithms 
which require both CPU and memory at the DLSw endpoints in direct proportion to 
the number transport connections.   The DLSw Scalability group has identified 
two scenarios where the number of transport connections can become significant 
resulting in excessive overhead and corresponding equipment costs (in memory 
and CPU).   The first scenario is found in highly meshed DLSw configurations 
where the number of transport connections approximates n2 (where n is the 
number of DLSws).  This is typically found in DLSw networks supporting N
etBIOS.  The second scenario is found  in networks  where many remote locations 
communicate to few central sites.  In this case, the central sites must support 
n transport connections  (where n is the number of remote sites).    In both 
scenarios the resultant transport connection overhead is considered undesirable 
depending upon the value of n.   

z LLC2 overhead

RFC 1795 specifies that each DLSw provides local termination for the LLC2 (SDLC 
or other SNA reliable data link  protocol) sessions traversing the SSP.   
Because these reliable data links also provide guaranteed in order packet 
delivery, the memory and CPU overhead of  maintaining these connections can 
also become significant.   This is particularly undesirable in the second 
scenario described above.  This is because the number of reliable connections 
maintained at the central site is the aggregate of the connections maintained 
at each remote site.  

It is not the intent of this document to address all the undesirable 
scalability issues associated with RFC 1795.   This paper identifies protocol 
enhancements to RFC 1795 using the inherent multicast capabilities of the 
underlying transport network to improve the scalability of RFC 1795.   It is 
believed that the enhancements defined, herein,  will address many of the 
issues identified such as: administration, address resolution,  broadcast 
packets, and to a lesser extent transport overhead.   This paper will not 
address LLC2 overhead.   Subsequent efforts by the AIW and/or DLSw Scalability 
group may address the unresolved scalability issues.

While it is the intent of this paper to accommodate all transport protocols as 
best as is possible, it is recognized that the multicast capabilities of many 
protocols is not yet well defined, understood, or implemented. Since TCP is the 
most prevalent DLSw transport protocol in use today, the DLSw Scalability group 
has chosen to focus its definition around TCP based multicast services.  Within 
the protocol definitions, efforts will be made to accommodate the potential 
application of other transport multicast services as best as can be done at 
this time.  But this specification will only address the implementation detail 
of TCP based multicast services. 

This proposal does not consider the impacts of IPv6 as this was considered too 
far from widespread use at the time of writing.

Overview

This paper describes the use of multicast services within the transport network 
to improve the scalability of DLSw based networking.   There are only a few 
main components of this proposal:

z Single session TCP connections
 
 RFC 1795 defines a negotiation protocol for DLSws to chose either two 
unidirectional or one bi-directional TCP connection.    DLSws implementing the 
enhancements described in this document must support and use(whenever required 
and possible)a single bi-directional TCP connection between DLSw peers. That is 
to say that the single tunnel negotiation support of RFC 1795 is a prerequisite 
function to this set of enhancements. Use of two unidirectional TCP connections 
is only allowed (and required)for migration purposes when communicating with 
DLSws that do not implement these enhancements.
 
 Note: The negotiation process and protocol state machines for single tunnel 
negotiation is described in RFC 1795.  Reference that document for further 
implementation detail.  
 
z TCP connections on demand
 
 Two DLSws will only establish a TCP connection when necessary.  SSP 
connections to DLSws which do not implement this enhancement are assumed to be 
established by means defined outside this paper.  DLSws implementing this 
enhancement utilize UDP based transport services to send address resolution 
packets (CANUREACH_ex, NETBIOS_NQ_ex, etc.).  If a positive response is 
received, then a TCP connection is only established to the associated DLSw peer 
if one does not already exist.  Correspondingly, TCP connections are brought 
down when there are no circuits to a partner DLSw for an implementation defined 
period of time. 
   
z Address resolution through UDP 
 
 The main thrust of this paper is to utilize non-reliable transport and the 
inherent efficiencies of multicast protocols whenever possible and applicable 
to reduce network overhead.  Accordingly, the address resolution protocols of 
SNA and NetBIOS are sent over the non-reliable transport of IP, namely UDP.  In 
addition, IP multicast/unicast services are used whenever address resolution 
packets must be sent to multiple destinations. This avoids the need to maintain 
TCP SSP connections between two DLSws when no circuits are active.  
CANUREACH_ex and ICANREACH_ex packets can be sent to all the appropriate DLSw 
partners without the need for preconfigured peers or pre-established TCP/IP 
connections.  In addition, most multicast services (including TCPs MOSPF, DVM
RP, MIP, etc.) replicate and propagate messages only as necessary to deliver to 
all multicast members.   This avoids duplication and excessive bandwidth 
consumption in the transport network.  
 
 To further optimize the use of WAN resources, address resolution responses are 
sent in a directed fashion (i.e., unicast) via UDP transport whenever 
possible.   This avoids the need to setup or maintain TCP connections when they 
are not required.  It also avoids the bandwidth costs associated with 
broadcasting. 
 
 Note: It is also permitted to send some address resolution traffic over 
existing TCP connections.  The conditions under which this is permitted are 
detailed in section 6.
 
z NetBIOS broadcasts over UDP

In the same manner as above, NetBIOS broadcast packets are sent via UDP 
(unicast and multicast) whenever possible and appropriate. This avoids the need 
to establish TCP connections between DLSws when there are no circuits 
required.   In addition, bandwidth in the transport network is conserved by 
utilizing the efficiencies inherent to multicast service implementation.  
Details covering identification of these packets and proper propagation methods 
are described in section 9.

Multicast Groups and Addressing 

IP multicast services provides an unreliable datagram oriented delivery service 
to multiple parties. Communications is accomplished by sending and/or listening 
to specific multicast addresses.  When a given node sends a packet to a 
specific address (defined to be within the multicast address range), the IP 
network (unreliably) delivers the packet to every node listening on that 
address.  

Thus, DLSws can make use of this service by simply sending and receiving (i.e., 
listening for) packets on the appropriate multicast addresses. With carefully 
planning and implementation, networks can be effectively partitioned and 
network overhead controlled by sending and listening on different addresses 
groups.  It is not the intent of this paper to define or describe the 
techniques by which this can be accomplished.  It is expected that the 
networking industry (vendors and end users alike) will determine the most 
appropriate ways to make use of the functions provided by use of DLSw multicast 
transport services.   

Using Multicast Groups

The multicast addressing as described above can be effectively used to limit 
the amount of broadcast/multicast traffic in the network.  It is not the intent 
of this document to describe how individual DLSw/SSP implementations would 
assign or chose group addresses.   The specifics of how this is done and 
exposed to the end user is an issue for the specific implementor.  In order to 
provide for multivendor interoperability and simplicity of configuration, 
however, this paper defines a single IP multicast address, 224.0.10.000, to be 
used as a default DLSw multicast address.  If a given implementation chooses to 
provide a default multicast address, it is recommended this address be used.  
In addition, this address should be used for both transmitting and receiving of 
multicast SSP messages.  Implementation of a default multicast address is not, 
however, required.

DLSw Multicast Addresses

For the purpose of long term interoperability, the AIW has secured a block of 
IP multicast addresses to be used with DLSw.  These addresses are listed below:

Address Range     Purpose
------------------------------------------------------------------------------------------
224.0.10.000   Default multicast address 
224.0.10.001-191   User defined DLSw multicast groups
224.0.10.192-255   Reserved for future usage in DLSw enhancements

DLSw Message Transports

With the introduction of DLSw Multicast Protocols,  SSP messages are now sent 
over two distinct transport mechanisms:  TCP/IP connections and UDP datagrams.  
Furthermore, the UDP datagrams can be sent to two different kinds of IP 
addresses: unique IP addresses (generally associated with a specific DLSw), and 
multicast IP addresses (generally associated with a group of DLSws).   

Single Session TCP/IP Connections

RFC 1795 defines the use of two unidirectional TCP/IP sessions between any pair 
of DLSw partners using read port number 2065 and write port number 2067.  
Additionally, RFC 1795 allows for implementations to optionally use only one 
bi-directional TCP/IP session.  Using one TCP/IP session between DLSw partners 
is believed to significantly improve the performance and scalability of DLSw 
protocols.  Performance is improved because TCP/IP acknowledgments are much 
more likely to be piggy-backed on real data when TCP/IP sessions are used 
bi-directionally.  Scalability is improved because fewer TCP control blocks, 
state machines, and associated message buffers are required.  For these 
reasons, the DLSw enhancements defined in this paper REQUIRE the use of single 
session TCP/IP sessions.  

Accordingly, DLSws implementing these enhancements must carry the TCP 
Connections Control Vector in their Capabilities Exchange.  In addition, the 
TCP Connections Control Vector must indicate support for 1 connection.  

TCP Connection establishment sequences and state machines remain the same as 
defined in RFC 1795.  As an optional enhancement, however, multicast capable 
DLSw nodes may chose not to establish a second TCP connection (local port 
2067)upon receipt of a TCP connection indication from another multicast capable 
DLSw partner (as indicated in the received Capabilities Exchange message).  In 
this case, the receiving DLSw simply responds with its capabilities over the 
newly established TCP connection.

TCP/IP Connections on Demand

As is the case in RFC 1795, TCP/IP connections are established between DLSws.  
Unlike RFC 1795, however, TCP/IP connections are only established to carry 
reliable circuit data (i.e., LLC2 based circuits).  Accordingly, a TCP/IP 
connection is only established to a given partner DLSw when the first circuit 
to that DLSw is required (i.e., the origin DLSw must send a CANUREACH_CS to a 
target DLSw partner and there is no existing TCP connection between the two).  
In addition, the TCP/IP connection is brought down an implementation defined 
amount of time after the last circuit has terminated.  In this way, the 
overhead associated with maintaining TCP connections is minimized. 

With the advent of TCP connections on demand, the activation and deactivation 
of TCP connections becomes a normal occurrence as opposed to the exception 
event it constitutes in RFC 1795.  For this reason, it is recommended that 
implementations carefully consider the value of SNMP traps for this condition.

TCP Connections on Demand Race Conditions
Non-circuit based SSP packets (e.g.,CANUREACH_ex, etc.) may still be 
sent/received over TCP connections after all circuits have been terminated.  
Taking this into account implementations should still gracefully terminate 
these TCP connections once the connection is no longer supporting circuits. 
This may require an implementation to retransmit request frames over UDP when 
no response to a TCP based unicast request is received and the TCP connection 
is brought down.  This is not required in the case of multicast requests as 
these are received over the multicast transport mechanism.  

UDP Datagrams

As mentioned above, UDP datagrams can be sent two different ways: unicast 
(e.g., sent to a single unique IP address) or multicast (i.e., sent to an IP 
multicast address).  Throughout this document, the term UDP datagram will be 
used to refer to SSP messages sent over UDP, while unicast and multicast SSP 
messages will refer to the specific type/method of UDP packet transport.   In 
either case, standard UDP services are used to transport these packets.  In 
order to properly parse the inbound UDP packets and deliver them to the SSP 
state machines, all DLSw UDP packets will use the destination port of 2065. 
In addition, the checksum function of UDP remains optional for DLSw SSP 
messages.  It is believed that the inherent CRC capabilities of all data link 
transports will adequately protect SSP packets during transmission.  And the 
incremental exposure to intermediate nodal data corruption is negligible.  For 
further information on UDP packet formats see the Frame Formats section.

UDP SSP Packet Handling  

In order to accommodate future AIW and vendor specific enhancements, 
implementations must ignore unrecognized packets (or unrecognized portions 
thereof)when received over the UDP transport (unicast or multicast).  A packet 
is considered to be unrecognized if it does not adhere to the defined SSP 
format listed in RFC 1795 or this document.  A portion of a packet is 
considered to be unrecognized if it contains undefined subvectors in properly 
defined positions.  In this case, those portions of the packet that are 
recognized should be honored and processed accordingly.  Those portions which 
are unrecognized should be ignored. 

Vendor Specific Functions over UDP 

In order to accomodate vendor specific capabilities over UDP transport, a new 
SSP packet format has been defined.  This new packet format is required because 
message traffic of this type is not necessarily preceeded by a capabilities 
exchange.  Accordingly, DLSws wishing to invoke a vendor specific function may 
send out this new SSP packet format over UDP.  Using the rules described above, 
implementations which do not understand this new packet format will ignore the 
message.   The precise format for this new packet type are described below in 
the Frame Formats section.
Unicast UDP Datagrams

Generically speaking, a unicast UDP datagram is utilized whenever an SSP 
message (not requiring reliable transport) must be sent to a unique set of 
DLSw.  This avoids the overhead of having to establish and maintain TCP 
connections when they are not required for reliable data transport.

A typical example of when unicast UDP might be used would be 
an ICANREACH_ex response from a peer DLSw (with which no TCP connection 
currently exists).  In this case, the sending DLSw knows the IP address of the 
intended receiver and can simply send the response via unicast UDP.   In 
addition, there are a number of NetBIOS cases where unicast UDP is used to 
handle UI frames directed to a specific DLSw (e.g., NetBIOS STATUS_RESPONSE).   
Further detail is provided  in the NetBIOS section of this document.  

Multicast UDP Datagrams

In a broad sense, multicast UDP datagrams are used whenever a given SSP message 
must be sent to multiple DLSw peers.  In the case of SNA, this is primarily the 
CANUREACH_ex packets.  In the case of NetBIOS, multicast datagrams are used to 
send  broadcast UI frames such as NetBIOS user datagrams and broadcast 
datagrams.  

Note, however, it is sometimes possible to avoid broadcasting certain NetBIOS 
frames that would otherwise be broadcast in the LAN environment.  This is 
typically accomplished using name caching techniques not described in this 
paper.  In cases of this type when a single  destination DLSw can be 
determined, unicast transport can be used to send the broadcast NetBIOS frame 
to a single destination.  A more detailed listing of NetBIOS SSP packets and 
transport methods can be found in the NetBIOS section of this document.

Unicast UDP Datagrams in Lieu of IP Multicast 

Because the use of IP multicast services is actually a function of IP itself 
and not DLSw proper, it is possible for implementations to simply make use of 
the UDP transport mechanisms described in this paper without making direct use 
of the IP multicast function.  While this is not considered to be as efficient 
as using multicast transport mechanisms, this practice is not explicitly 
prohibited.  

Implementations which chose to make use of  UDP transport in this manner must 
first know the IP address of all the potential target DLSws and send individual 
unicast packets to each.  How this information is obtained and/or maintained is 
outside the scope of this paper.  

As a matter of compliance, implementers need not send SSP packets outbound over 
UDP as there are some conditions where this may not be necessary or desirable.  
It is, however, required that implementers provide an option to receive SSP 
packets over UDP. 

TCP Transport

Despite the addition of UDP based packet transport, TCP remains the fundamental 
form of communications between DLSws.  In particular, TCP is still used to 
carry all LLC2 based circuit data. 

Throughout this document wherever UDP unicast (not multicast) is discussed, the 
reader should be aware that TCP may be used instead.  Moreover, it is strongly 
recommended that TCP be used in preference to UDP whenever a TCP connection to 
the destination already exists.   Implementations, however, should be prepared 
to receive SSP packets from either transport (TCP or UDP). 

Migration Support

It is anticipated that some networks will experience a transition stage where 
both RFC 1795 (referred to as non-multicast DLSws) and enhanced RFC 1795 DLSws 
(those implementing these enhancements, referred to as multicast capable DLSws) 
will exist in the network at the same time.  It will be important for these two 
DLSw node types to interoperate and thus the following accommodations for 
non-multicast DLSws are required: 

Capabilities Exchange

In order to guarantee both backward and forward capability, DLSws which 
implement these multicast enhancements will carry a Multicast Capabilities 
Control Vector in their capabilities exchange (see RFC 1795 for an explanation 
of capabilities exchange protocols).   Presence of the Multicast Capabilities 
control vector indicates support for the protocols defined in this document on 
a per DLSw partner basis.  Conversely, lack of the Multicast Capabilities 
control vector indicates no support for these extensions on a per DLSw partner 
basis.  

In addition, presence of this control vector mandates a TCP Connections Control 
Vector indicating support for 1 TCP connection in the same Capabilities 
exchange. If a multicast capable DLSw receives a Capabilities Exchange CV that 
does not meet the above criteria, then the associated capabilities exchange is 
rejected with a negative response using reason code x000D: Inconsistent 
Multicast and TCP Connections control vectors 

Connecting to non-multicast capable nodes

It is assumed that TCP connections to DLSws which do not support multicast 
services are established by some means outside the scope of this paper (i.e., 
non-multicast partner addresses are configured by the customer).   TCP 
connections must be established and maintained to down level nodes in the exact 
same manner as RFC 1795 requires, establishes, and maintains them.  And because 
non-multicast DLSws will not indicate support for multicast services in their 
capabilities exchange, a multicast capable DLSw will know all its non-multicast 
peers. 

Communicating with multicast capable nodes 

Because non-multicast nodes will not receive SSP frames via UDP (unicast or 
multicast) transmission, SSP messages to these DLSws must be sent over TCP 
connections.   Therefore, nodes which implement the multicast protocol 
enhancements must keep track of which DLSw partners do not support multicast 
extensions (as indicated in the capabilities exchange).  When a given packet is 
sent out via multicast services, it must also be sent over multicast UDP(to 
reach other multicast capable DLSws) and over the TCP connection to each 
non-multicast node.   And although the multicast service requires periodic 
retransmissions (for reliability reasons), this is not the case with TCP 
connections to non-multicast nodes. Therefore, multicast capable DLSws should 
not resend SSP packets over TCP transport connection but rather, rely upon TCP 
to recover any lost packets. Furthermore, communications with non-multicast 
nodes should be in exact compliance with RFC 1795 protocols.  

When sending a unicast UDP message, it is important to know that the 
destination DLSw supports multicast services.  This knowledge can be obtained 
from previous TCP connections/capabilities exchanges or inferred from a 
previously received UDP message, but how this information is obtained is 
outside the scope of this paper.  In the latter case, if the DLSw is 
non-multicast, then there would be a TCP connection to it and it would be known 
to be non-multicast.  If it is multicast capable and a TCP connection is in 
existence, then its level is known (via the prior capabilities exchange).  If 
its capabilities are not known and there is not an existing TCP connection, 
then it can be implied to be multicast capable (by lack of a TCP connection) by 
virtue of a cached entry but no active TCP connection (e.g., TCP peer on demand 
support).  This inference, however, could be erroneous in cases where the TCP 
connection (to a non-multicast DLSw) has failed for some reason. But normal UDP 
based unicast verification mechanisms will detect no active path to the 
destination and circuit setup will proceed correctly (i.e., succeed or fail 
inaccordance with true connectivity). 

SNA Support 
Note: This paper does not attempt to address the unique issues presented by 
SNA/HPR and its non-ERP data links

In SNA protocols the generalized packet sequence of interest is a test frame 
exchange followed by an XID exchange.  In all cases, DLSw uses the CANUREACH 
and ICANREACH SSP packets to complete address resolution and circuit 
establishment.  The following table describes how these packets are transported 
via UDP between two multicast capable DLSws.  

                       Transport
Message Event  Action  Mechanism    Retry
--------------------------------------------------------------------------
TEST    SEND CANUREACH Multicast/Unicast Yes  
TEST RESPONSE  SEND ICANREACH Unicast 

The following paragraphs provide more detail on how UDP transport and multicast 
protocol enhancements are used to establish SNA data links.

Address Resolution

When a DLSw receives an incoming test frame from an attached data link, the 
assumption is that this is an exploratory frame in preparation for an XID 
exchange and link activation.  The DLSw must determine a correlation between 
the destination LSAP (mac and sap pairing) and some other DLSw in the transport 
network.   This paper generically refers to this process as address resolution. 

Explorer frames

Unicast messages may be sent over a TCP connection to a multicast capable 
partner if such a connection already exists in order that they take advantage 
of the guaranteed delivery of TCP.  This is particularly recommended for 
ICANREACH_ex and NAME_RECOGNIZED_ex frames where the guaranteed delivery of TCP 
avoids the need to send unicast retries for these responses.

Example SNA SSP Message Sequence 

The following diagram provides an example sequence of flows associated with an 
SNA LLC circuit setup.    All flows and states described below correspond 
precisely with those defined in RFC 1795.  The only exception is the addition 
of a TCP connection setup and DLSw capabilities exchange that occurs when the 
origin DLSw must send a CANUREACH_CS and no TCP connection yet exists to the 
target DLSw partner.  

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                    disconnected

TEST_cmd      DLC_RESOLVE_C    CANUREACH_ex               TEST_cmd
----------->  ----------->     ----------->               ---------->
   TEST_rsp   DLC_RESOLVE_R    ICANREACH_ex                 TEST_rsp
 <---------    <-----------   <-----------                <----------
null XID      DLC_XID
----------->  ----------->
              circuit_start

     TCP Connection Setup
     <------------->
     Capabilities Exch.
     <------------->
      CANUREACH_cs    DLC_START_DL
      ----------->    ----------->
          resolve_pending
                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-------------
           circuit_established                circuit_pending
                              REACH_ACK
                              ----------->  circuit_established

                              XIDFRAME         DLC_XID       null XID
                              ----------->     --------->    -------->
        XID        DLC_XID        XIDFRAME         DLC_XID          XID
  <--------   <-----------    <-----------    <-----------    <--------
    XIDs         DLC_XIDs      XIDFRAMEs        DLC_XIDs         XIDs
<---------->  <---------->  <------------>  <------------>  <--------->
SABME         DLC_CONTACTED   CONTACT         DLC_CONTACT     SABME
----------->  ----------->    ----------->    ----------->    -------->
              connect_pending                 contact_pending

          UA     DLC_CONTACT     CONTACTED    DLC_CONTACTED          UA
  <---------   <-----------   <-----------    <-----------    <--------
                  connected                        connected
IFRAMEs       DLC_INFOs        IFRAMEs        DLC_INFOs       IFRAMEs
<---------->  <----------->  <------------>  <------------>  <-------->

Circuit Setup  

Circuit setup is accomplished in the same manner as described in RFC 1795.  
More specifically, CANUREACH_cs, ICANREACH_cs, REACH_ACK, XIDFRAME, etc. are 
all sent over the TCP connection to the appropriate DLSw.   This, of course, 
assumes the existence of a TCP connection between the DLSws.   If the sending 
DLSw (sending a CANREACH_cs ) detects no active TCP connection to the partner 
DLSw, then a TCP connection setup is initiated and the packet sent.  All other 
circuit setup (and takedown) related sequences are now passed over the TCP 
connection. 

UDP Reliability 

It is important to note, that UDP (unicast and multicast)transport services do 
not provide a reliable means of delivery.  Existing RFC 1795 protocols 
guarantee the delivery (or failure notification) of CANUREACH_ex and 
ICANREACH_ex messages.  UDP will not provide the same level of reliability.  It 
is, therefore, possible that these messages may be lost in the network and 
retries will be necessary.  

Retries 

Test Frames are generally initiated by end stations every few seconds.  Many 
existing RFC 1795 DLSw implementations take advantage of the reliable SSP TCP 
connections and filter out end station Test frame retries when a CANUREACH_ex 
is outstanding.   Given the unreliable nature of UDP transport for these 
messages, however, this filtering technique may not be advisable.  Neither RFC 
1795 or this paper address this issue specifically.  It is simply noted that 
the UDP transport mechanism is unreliable and implementations should take this 
into account when determining a scheme for Test frame filtering and explorer 
retries.  Accordingly, the Retry section in the table below only serves as an 
indicator of situations where retries may be desirable and/or necessary, but 
doesnt not imply any requirement to implement retries. Also note, that retry 
logic only applies to non-response type packets.  It is not appropriate to 
retry response type SSP packets (i.e., ICANREACH_ex) as there is no way of 
knowing if the original response was ever received (and whether retry is 
necessary). So in the case of SNA, CANUREACH messages may need retry logic and 
ICANREACH messages do not.

NetBIOS

With the introduction of DLSw Multicast transport, all NetBIOS UI frames are 
carried outside the TCP connections between DLSws (i.e., via UDP datagrams).   
The following table defines the various NetBIOS UI frames and how they are 
transported via UDP between multicast capable DLSws:

                  Transport
Message Event  Action   Mechanism    Retry
--------------------------------------------------------------------------
ADD_GROUP_NAME_QUERY SEND DATAFRAME  Multicast   Yes  
ADD_NAME_QUERY  SEND NETBIOS_ANQ  Multicast  Yes
ADD_NAME_RESPONSE  Send NETBIOS_ANR  Unicast1      
NAME_IN_CONFLICT  SEND DATAFRAME  Multicast   Yes
STATUS_QUERY  SEND DATAFRAME  Unicast/Multicast Yes  
TERMINATE_TRACE (x07) SEND DATAFRAME  Multicast 
TERMINATE_TRACE (X13) SEND DATAFRAME  Multicast 
DATAGRAM   SEND DATAFRAME  Unicast/Multicast2
DATAGRAM_BROADCAST SEND DATAFRAME  Multicast
NAME_QUERY   SEND NETBIOS_NQ_ex Unicast/Multicast Yes
NAME_RECOGNIZED  Send NETBIOS_NR_ex Unicast3     
STATUS_RESPONSE  Send DATAFRAME  Multicast4     

Note 1:
Upon receipt of an ADD_NAME_RESPONSE frame, a NETBIOS_ANR SSP message is 
returned via unicast UDP to the originator of the NETBIOS_ANQ message.

Note 2:
DATAGRAM frames may be sent either Unicast or Multicast UDP.  If the 
implementation has sufficient cached information to resolve the NetBIOS 
datagram destination to a single DLSw peer, then the SSP message can and should 
be sent via unicast.  If the cache does not contain such information then the 
resultant SSP message must be sent via multicast UDP.  Note that this frame is 
sent as either a DATAFRAME or DGRMFRAME according to the rules as specified in 
RFC 1795. 

Note 3:
Upon receipt of a NAME_RECOGNIZED frame, a NETBIOS_NR_ex SSP message is 
returned via unicast UDP to the originator of the NETBIOS_NQ_ex frame.  Notice 
that although the NAME_RECOGNIZE frame is sent as an ARE (source routing LANs 
only) frame, the resultant NETBIOS_NR_ex is sent as a unicast UDP directed 
response to the DLSw originating the NETBIOS_NQ_ex.   This is because there is 
no value in sending NETBIOS_NR_ex as a multicast packet in the transport 
network.  The use of ARE transmission in the LAN environment is to accomplish 
some form of load sharing in the source routed LAN environment.  Since no 
analogous capability exists in the (TCP) transport network, it is not necessary 
to emulate this function there.   It is important to note, however, that when co
nverting a received NETBIOS_NR_ex to a NAME_RECOGNIZED frame, the DLSw sends 
the NAME_RECOGNIZED frame onto the LAN as an ARE (source routing LANs only) 
frame.  This preserves the source route load sharing in the LAN environments on 
either side of the DLSw transport network.  

Note 4:
Although RFC 1795 does not attempt to optimize STATUS_RESPONSE processing, it 
is possible to send a STATUS_RESPONSE as a unicast UDP response.  To do this, 
DLSws receiving an  incoming SSP DATAFRAME containing aSTATUS_QUERY must 
remember the originating DLSws address and STATUS_QUERY correlator.  Then upon 
receipt of the corresponding STATUS_RESPONSE, the DLSw responds via unicast UDP 
to the originating DLSw(using the remembered originating DLSw address). Note, 
however, that in order  to determine whether a frame is a STATUS_QUERY, all 
multicast capable DLSw implementations will need to parse the contents of 
frames that would normally be sent as DATAFRAME SSP messages.  

All other multicast frames are sent into the transport network using the 
appropriate multicast group address.  

Address Resolution

Typical NetBIOS circuit setup using multicast services is  essentially the same 
as specified in RFC 1795.   The only significant difference is that 
NETBIOS_NQ_ex messages are sent via UDP to the appropriate multicast IP address 
and the NETBIOS_NR_ex is sent via unicast UDP to the DLSw originating the 
NETBIOS_NQ_ex.

Circuit Setup 

Following successful address resolution, a NetBIOS end station typically sends 
a SABME frame to initiate a formal LLC2 connection.   Receipt of this message 
results in  normal circuit setup as described in RFC 1795 (and the SNA case 
described above).  That is to say that the CANUREACH_cs messages etc. are sent 
on a TCP connection to the appropriate partner DLSw.  If no such TCP connection 
exists, one is brought up. 

Example NetBIOS SSP Message Sequence

The following diagram provides an example sequence of flows associated with a 
NetBIOS circuit setup.    All flows and states described below correspond 
precisely with those defined in RFC 1795.  The only exception is the addition 
of a TCP connection setup and DLSw capabilities exchange that occurs when the 
origin DLSw must send a CANUREACH_CS and no TCP connection yet exists to the 
target DLSw partner.  

 ======                            ___                           ======
 |    |        ---------        __/   \__       ---------        |    |
 |    |      __|  _|_  |__     /   IP    \    __|  _|_  |__      |    |
 ======        |   |   |      <  Network  >     |   |   |        ======
/______\       ---------       \__     __/      ---------       /______\
 Origin       Origin DLSw         \___/        Target DLSw      Target
 Station        partner                          partner        Station

              disconnected                     disconnected

NAME_QUERY    DLC_DGRM        NETBIOS_NQ_ex   DLC_DGRM       NAME_QUERY
----------->  ----------->    ----------->    ----------->   --------->

   NAME_RECOG    DLC_DGRM      NETBIOS_NR_ex     DLC_DGRM    NAME_RECOG
 <-----------  <------------   <-----------    <-----------  <---------

SABME         DLC_CONTACTED   
----------->  ----------->    
               circuit_start   
     TCP Connection Setup
     <------------->
     Capabilities Exch.
     <------------->
      CANUREACH_cs    DLC_START_DL
      ----------->    ----------->
          resolve_pending
       
                                ICANREACH_cs    DLC_DL_STARTED
                                <-----------    <-----------
            circuit_established                circuit_pending
                              REACH_ACK
                              ----------->   circuit_established

                              CONTACT         DLC_CONTACT     SABME
                              ----------->    ----------->    --------->
             connect_pending                 contact_pending

          UA   DLC_CONTACT       CONTACTED    DLC_CONTACTED           UA
  <---------  <-----------    <-----------    <-----------    <---------
                connected                       connected

   IFRAMEs       DLC_INFOs       IFRAMEs        DLC_INFOs       IFRAMEs
<------------> <------------> <------------>  <------------>  <-------->

Multicast Reliability and Retries

In the case of NetBIOS, many more packets are being sent via UDP than in the 
SNA case.  Therefore, the exposure to the unreliability of these services is 
greater than that of SNA. For address resolution frames, such as NAME_QUERY, 
etc., successful message delivery is an issue.   In addition, the retry 
interval for these types of frames is considerably shorter than SNA with the 
defaults being:  retry interval = 0.5 seconds and retry count = 6.   Once 
again, neither RFC 1795 or this paper attempt to address the issue of LAN frame 
filtering optimizations. This issue is outside the scope of this paper.  But it 
is important for implementers to recognize the inherent unreliable nature of 
UDP transport services for frames of this type and to implement retry schemes 
that are appropriate to successful operation.  Again, it is only appropriate to 
consider retry of non-response type packets.  Specific NetBIOS messages where 
successful message delivery is considered important (and retries possibly 
necessary) are indicated in the table above with an Yes in the Retry column.
Sequencing 

It is important to note that UDP transport services do not provide guaranteed 
packet sequencing like TCP does for RFC 1795.  In a steady state network, in 
order packet delivery can be generally assumed.   But in the presence of 
network outages and topology changes, packets may take alternate routes to the 
destination and arrive out of sequence with respect to their original 
transmission order.    For SNA address resolution this should not be a problem 
given that their is no inherent significance to the order of packets being 
transmitted via UDP.   

In the case of NetBIOS, in order delivery is not guaranteed in the normal case 
(e.g., LANs).  This is because LAN broadcasting mechanisms suffer the same 
problems of packet sequencing as do wan multicast mechanisms.   But one might 
argue the greater likelihood of topology related changes in the wan environment 
and thus a greater level of concern.  The vast majority of NetBIOS UI frames 
(being handled via UDP and Multicast) have correlator values and do not rely 
upon packet sequencing. 

The only NetBIOS frames of special note would be: DATAGRAM, DATAGRAM_BROADCAST, 
and STATUS_RESPONSE.  In the case of DATAGRAM and DATAGRAM_BROADCAST it is 
generally assumed that datagrams do not provide any guarantee of in order 
packet delivery.  Thus applications utilizing this NetBIOS service are assumed 
to have no dependency on in order packet delivery.   STATUS_RESPONSE can 
actually be sent as a sequence of STATUS_RESPONSE messages.  In cases where 
this occurs, the STATUS_RESPONSE will be exposed to potential out of sequence 
delivery. 

Frame Formats

Multicast Capabilities Control Vector

This control vector is carried in the Capabilities Exchange Request.  When 
present, it must be accompanied by a TCP Connections Control Vector indicating 
support for 1 TCP/IP connection.  Like all control vectors in this SSP message, 
it is an LT structure.  LT structures consist of a 1 byte length field followed 
by a 1 byte type field.   The length field includes itself as well as the type 
and data fields.  

Byte Bit  Description
0 0-7  Length, in binary, of the multicast capabilities control            
vector (inclusive of this byte)

1 0-7  Type:  x8C 

2 0-7  Multicast Version Number: 
A binary numerical representation of the level of multicast services provided.  
The protocols as identified in this document constitute version one.   
Accordingly, x01 is encoded in this field.  Any subsequent version must provide 
the services of all previous versions.

3-4   Reserved 

5-n   Optional Control Vectors: parsed LT if present.          Currently, none 
defined. 

The intended use of this CV for Multicast support is to detect when the 
multicast CUR_ex flows will suffice between partners.  If this CV is present in 
a cap-ex from a partner, that partner is also multicast capable and therefore 
does not need to receive CUR_ex messages over the TCP link  that exists between 
them (and there must be one or else the cap-ex would not have flowed) because 
it will receive the multicast copies. 

A DLSw includes this control vector on a peer-wise basis.  That is to say, that 
a DLSw implementation may support multicast services but choose not to indicate 
this in its capabilities exchange to all partners. Therefore, a DLSw may 
include this capabilities CV with some DLSw peers and not with others.  Not 
including this vector can be used to force TCP connections with other multicast 
capable nodes and degrade to normal RFC 1795 operations.  This capability is 
allowed to provide greater network design flexibility.  

All DLSws implementing these enhancements must quietly ignore any unrecognized 
optional CVs in bytes 5 onwards.  If a Multicast capabilities CV is received 
containing unrecognized optional CVs, the receiving DLSw must not reject the 
capabilities exchange for this reason (though it is permitted to reject the 
cap-ex with a negative response if the vector is badly formatted or if there 
are other errors in the cap-ex).

DLSw Capabilities Negative Response

DLSws that implement these enhancements must provide support for both multicast 
version 1 and single TCP connections.  This means that a multicast control 
vector must be accompanied by the TCP Connections control vector within a given 
capabilities exchange.  Moreover, the TCP Connections CV must indicate use of 1 
TCP connection.  If a multicast capable DLSw receives a capabilities exchange 
with a multicast CV, but either a missing or inappropriate TCP Connections CV 
(i.e., connections not equal to one), then the inbound capabilities exchange 
should be rejected with a DLSw capabilities exchange negative response (see RFC 
1795) using the following new reason code:

x000D Inconsistent Multicast Capabilities and TCP Connections CV recieved on 
the inbound Capabilites exchange

UDP Packets

SSP frame formats are defined in RFC 1795.  Multicast protocol enhancements do 
not change these formats in any way.  The multicast protocol enhancements, 
however, do introduce the notion of SSP packet transport via UDP.  In this 
case, standard UDP services and headers are used to transport SSP packets. 

The following section describes the proper UDP header for DLSw SSP packets.

Byte Bit  Description
0-1   Source Port address
In DLSw multicast protocols, this particular field is not relevant.  It may be 
set to any value.

2-3   Destination Port address
   Always set to 2065 

4-5   Length

6-7   Checksum  
The standard UDP checksum value.  Use of the UDP checksum function is 
optional.  

Vendor Specific UDP Packets

In order to accomodate the addition of vendor specific functions over UDP 
transport, a new SSP packet header has been defined.  It matches the current 
SSP packet header with two notable exceptions:  

1) The Version Number field is set to x32 (ASCII 2) and now represents a packet 
type more than a DLSw version number.  More precisely, it is permitted and 
expected that DLSw may send packets of both types. 

2) The message length field is followed by a new 3 byte field that contains the 
specific vendors IEEE Organizationally Unique Identifier (OUI).  A value of 
zeros in this field implies an AIW standard.  

3) All fields following the new OUI field are defined outside this paper.

The following section defines this new header format:

Byte Bit  Description
0     DLSw packet type, Always set to x32 

1   Header Length
   Note: could be other than 72 

2-4   Vendor specific OUI
The IEEE Organizationally Unique Identifier (OUI) associated with the vendor 
specific function in question.  Note: A value of zeros implies an AIW standard

5-n   Defined by the OUI owner

---

From: Harry Silverstone <[email-masked]>
Date: Wed, 4 Sep 1996 21:44:05 -0400 (EDT)

Hi,

	I have read over the document and just had a few minor comments 
and a question.

 - In the section, LLC Overhead, the last paragraph/sentence refers to IPv6
   which I was thinking should probably be removed or placed together 
   with the comment on SNA/HPR.

 - In the section, Single session TCP connections, the piece "(whenever
   required and possible)", I think should be removed to minimize 
   misunderstandings. The following sentences explain what is being said.

   By the way, there is another section named simarily to this one;
   Single session TCP/IP Connections.

 - For the User defined DLSw Multicast group range, I trust that no one
   vendor can/should monopolize one of these addresses? Just asking..

 - Is there any special consideration needed for PU2.1? It;s connection
   may start with XIDs and not Test frames. 

 - typo in Retres section "doesnt not"

 That's it for me.

 ~harry